Public key cryptographic systems are designed to provide secure communication over insecure networks, including between parties that may not have had any previous communication. Such systems typically rely upon a public key infrastructure (PKI) comprising software, hardware, communication protocols, and related policies and procedures, one such example being the X.509 standard published by the International Telecommunication Union.
There are two common trust models used as part of a PKI. A web of trust model is based on a decentralized network and is used as part of systems such as Pretty Good Privacy™ (PGP). In contrast, a hierarchical model relies upon certain entities in the trust framework being commonly trusted by multiple parties, such mutual trust in such entities underpinning the system. Regardless of which trust model is used, when two parties interact for the first time by means of a PKI, each party uses the trust framework of a PKI in order to decide whether or not to trust the other party as being who they claim to be. This is commonly used, for example, in the context of web browsers accessing web servers over the Internet.
A common aspect of a typical PKI comprises digital certificates that use cryptographic protocols to reliably link certain information with an identity. For example, the X.509 standard defines public key certificates as comprising, among other things, a serial number, the identity of the issuer of the certificate, the subject (i.e. the entity identified by the certificate), the digital signature of the issuer, and a public key of the subject.
In a hierarchical PKI, certificates are divided into three types: end certificates, intermediate certificates, and root certificates. Root certificates and intermediate certificates are used to identify certificate authorities (CAs), that is, an entity in a PKI that issues digital certificates to third parties. Root certificates are self-signed, that is, the identity of the issuer of the certificate is the same as the subject of the certificate, in this case, a root CA. These certificates must either be axiomatically trusted or not trusted by a given third-party. Intermediate certificates are certificates issued to an intermediate CA by a root CA. End certificates are issued by certificate authorities to end users, such as a website host. In such a hierarchical PKI, whether a given end certificate is trusted by a particular individual is based on whether that particular individual trusts the issuer of the certificate (or any other issuer further up the certificate chain). In this way, individuals, upon receiving a certificate purporting to be of an arbitrary third-party (i.e. an end certificate), may traverse the certificate chain, starting from the end certificate, through one or more intermediate certificates, and terminating at a root certificate. If at any point an intermediate certificate or the root certificate is trusted, then the end certificate is similarly trusted. Such analysis of a certificate and its corresponding certificate chain, together with further security protocols as described herein, is commonly known to those skilled in the relevant art as validating a certificate.
Prior art PKIs may include mechanisms to provide additional security. Certificate revocation lists (CRLs) are lists published by certificate authorities to give public notice of certain certificates that they issued that are no longer valid (i.e. should no longer be trusted by third parties). Typically, in the context of the Internet, a digital certificate will include an Uniform Resource Locator (URL) to download a corresponding CRL, the assumption being that a given third party, upon receiving the certificate and deciding whether to trust it by traversing the certificate chain, as part of the validation process, will also access the CRL through the provided URL to determine whether or not the certificate has been revoked.
Another illustrative protocol, the Online Certificate Status Protocol (OCSP), operates by means of a query/response mechanism to similarly provide the status of a particular certificate. A corresponding OCSP responder may be specified by a digital certificate, the assumption again being that a given third party, upon receiving the certificate and deciding whether to trust it by traversing the certificate chain, as part of the validation process, will also query the OCSP responder through the provided URL to determine whether or not the certificate has been revoked. Still another well-known protocol for validating and reviewing the status of a given certificate is delegated path validation (DPV).
A common limitation to these existing mechanisms in the context of the Internet is that they depend upon the correct operation of underlying Internet services, particularly that of the Domain Name System (DNS) and network traffic routing more generally. For example, if a third-party (such as a nation-state) has the capability to return an incorrect Internet Protocol (IP) address to a given individual in response to a DNS query (e.g. in the course of attempting to access a specified URL to download a particular CRL), such third-party could prevent the individual from learning that a given certificate has been revoked. A similar consequence would arise if a third-party has the capability of interfering with the routing of network traffic between the given individual and, for example, an OCSP responder.